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MULTI-VENDOR INTERNET COMMERCE SYSTEM FOR E-COMMERCE 
APPLICATIONS AND METHODS THEREFOR 



Background of the Invention 

The following applications are related to the present disclosure and are incorporated by 
reference herein: a Provisional Application entitled "Method and Apparatus for E-Commerce 
Enabling an Object" by the same inventors, filed in the U.S. Patent and Trademark Office 
^ (USPTO) on June 30, 1999, and assigned S/N 60/141,898 (Attorney Docket No. 

CCTYP002P); the utility application resulting therefrom (having the same title), filed in the 
USPTO on November 30, 1999, and assigned S/N 09/451,469 (Attorney Docket No. 
CCTYP002JL 

The present invention relates to a multi -vendor Internet Commerce System for e- 
commerce application. More particularly, the present invention relates to an improved 
architecture for enabling e-commerce in an efficient and consumer-friendly way for a plurality 
of vendors through the Internet. 

Electronic commerce, or e-commerce, represents a highly convenient and efficient way 
for buyers and sellers to conduct transactions worldwide and at all times. In the current 
paradigm, the vendor having merchandise to offer typically implements a website at a vendor 
server, which may be maintained by the vendor's staff or hosted at a hosting facility. The 
vendor website typically includes a product database, representing the database of products to 
be sold, and a consumer database, representing the database of the vendor's customers and 
their profiles. To facilitate the transaction process, a variety of search, shopping cart, and 
checkout tools may be provided. In general, these tools facilitate the interaction between a 
specific vendor website and the consumer. On the consumer's side, the interaction typically 
takes place through an appropriate user interface at the client's terminal. In the current 
paradigm, one such user interface may represent a commercially available web browser such as 
Internet Explorer by Microsoft Corporation of Redmond, Washington or Netscape by America 
Online of Vienna, Virginia. 
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To facilitate discussion, Fig. 1 illustrates a simplified representation of a prior art e- 
commerce arrangement 100 between a consumer 102 and a vendor 103. To facilitate their 
electronic commerce activities, the interaction between consumer 1 02 and vendor 1 03 is 
facilitated through a terminal 104 and vendor website 108. As shown, both vendor website 108 
and terminal 1 04 are connected to the Internet 1 06. To conduct an e-commerce transaction 
with vendor 103 via the Internet 106, consumer 102 typically utilizes a commercially available 
browser at terminal 104. By way of example, consumer 102 may enter the URL (Universal 
Resource Locator) for the vendor website into a browser 1 10 in order to access the vendor 
website. In the example of Fig. 1, the URL may be, for example, 
http://www.agoodwebstore.com. 

The transmission of the URL from browser 1 10 to vendor website 108 is represented 
symbolically by path 1 12. Responsive to the receipt of the URL, vendor website 108 may 
return, over time, a plurality of pages to browser 1 10 on terminal 104 to permit consumer 102 
to sign in, conduct searches among the items of merchandise offered for sale, and to make a 
selection. The transmission of a page containing one or more products for sale is represented 
symbolically in Fig. 1 by path 1 14. 

At some point, consumer 102 may wish to select an item for purchase. In the example 
of Fig. 1, the selection of an item for purchase occurs when consumer 102 clicks on a shopping 
cart button 1 16, which causes a message that includes the description of the selected item to be 
transmitted to an electronic shopping cart associated with vendor 103 and to be added thereto. 
Generally, the electronic shopping cart resides at client browser 1 10 and contains items offered 
for sale by vendor 103. With reference to Fig. 1, the transmission of the description of the 
selected item is accomplished via a path 120. Once the selected item is added to the shopping 
cart associated with vendor 103, the process may proceed with consumer 102 continuing to 
search for and select additional items to be added to the shopping cart. 

If consumer 102 elects to checkout, consumer 102 may click on a "buy" button 126 on 
browser 1 10, which sends a checkout instruction via a path 128 from browser 1 10 to vendor 
website 108, as well as the items in the shopping cart stored locally at the client browser 1 10. 
At vendor website 108, the receipt of the checkout instruction may cause an invoice to be 
prepared using the list of items selected (which is stored in the shopping cart at vendor website 
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108). Taxes, handling and shipping charges, as well as any other discounts or markups may be 
calculated at this point, and the final invoice may be presented to consumer 102 via path 130 as 
an invoice page on browser 1 10. Unless consumer 102 is already a customer with vendor 
website 1 08, the payment page may also include a form to permit consumer 1 02 to fill out any 
necessary personal, payment, and shipping data. Exemplary data that may be required includes 
name, address, credit card number, ship address, ship method preferred, and the like. 
Consumer 102 may fill out the payment data form and transmit the completed form back to 
vendor website 108 via path 132 to permit vendor 103 to, for example, charge the credit card 
indicated for the items purchased and to ship to the address specified. 

Although the prior art e-commerce paradigm allows consumer 1 02 to shop for 
merchandise, select merchandise for payment, and complete the transaction at each vendor 
website in a fairly efficient manner, there are disadvantages. By way of example, since the 
process of entering the personal, payment, and shipping data is rather laborious, some vendors 
retain such confidential information at the vendor website to permit the vendor to furnish such 
information automatically the next time the same consumer purchases from that vendor's 
website again. In this case, the consumer is given a consumer ID and a password for 
authentication purposes on subsequent visits to the website. 

As can be appreciated by those skilled in the art, however, the fact that confidential 
personal, payment, and shipping data pertaining to the consumers are kept at the vendor poses a 
security risk. The security risk is increased if the consumer purchases from multiple Internet 
vendors and may have his or her confidential data kept at multiple websites throughout the 
Internet. 

Even if the security risk can be eliminated, the fact that each vendor website may issue 
a different set of consumer ID and password represents an inconvenience to the consumer. 
Although a consumer generally tries to keep the same consumer ID and password across 
multiple vendor websites, there may be times when, at a particular vendor website, the desired 
consumer ID and/or password is not available, and the consumer is then forced to choose 
another set of consumer ID/password. Over time, the average consumer may be burdened with 
having to memorize numerous sets of consumer ID/password and the websites that are 
applicable thereto. 




As mentioned before, the consumer has the option to place items into an electronic 
shopping cart prior to checking out. This paradigm allows the consumer to conveniently tally 
his or her intended purchases prior to paying for them. Over time, consumers have come to 
rely on this shopping cart paradigm and rely on the shopping cart. However, since the 
shopping cart of the prior art typically works only with the website that issues it, a consumer 
shopping at multiple websites may have multiple shopping carts with items therein pending 
and waiting to be checked out. Since each shopping cart contains only items from a single 
vendor, the consumer must contend with multiple shopping carts and juggle among them to 
keep track of items selected. This makes it difficult for the average consumer to, for example, 
quickly determine whether the total cost for the items selected across multiple vendors fits 
within the consumer's budget, or to quickly compare an item already placed in the shopping 
cart at one vendor website with another item that the consumer may be considering from 
another vendor website. 

Another disadvantage relates to the fact that the shopping cart of the prior art resides at 
the client browser (e.g., 1 10 of Fig. 1). If the consumer uses one terminal/browser to shop and 
place items into the prior art shopping cart but has not checked out and subsequently moves to 
another terminal to continue shopping, the consumer will be presented with another shopping 
cart, which does not have therein the items already picked and placed into the original shopping 
cart. This is so even though the consumer has been shopping with the same vendor all along. 
As can be appreciated by those skilled in the art, this is inefficient and creates confusion for the 
consumer. 

Still further, the fact that each vendor website currently maintains its own consumer 
database and/or implements its own shopper authentication/ID mechanism, its own shopping 
cart infrastructure, and/or its web-based checkout infrastructure represents a significant barrier 
to entry into e-commerce for many vendors who have yet to implement their e-commerce 
website. This is because these infrastructures require a significant investment of time and 
effort to set up and maintain. Furthermore, since these infrastructures are set up and 
maintained at each website, the duplication in effort represents collectively a wasteful use of 
time and money for e-commerce vendors as a group. 
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Additionally, the fact that each vendor website implements its own shopping cart and 
checkout facilities, the user interface of the shopping cart and/or the checkout page as well as 
the navigation steps involved therewith may vary widely from vendor site to vendor site. From 
the consumer's perspective, the effort required to learn different websites and become 
5 familiarized with their shopping carts and checkout procedures may discourage some 

consumers from fully utilizing the rich offerings of products and services on the Internet. 



In view of the foregoing, there are desired improved architectures and techniques 
therefor which enable e-commerce in an efficient and consumer-friendly way for a plurality of 
vendor websites through the Internet. 



y In accordance with one embodiment of the present invention, there is provided a multi- 
vendor Internet Commerce System which advantageously offers both consumer user- 
friendliness and ease of setup and maintenance for a plurality of e-commerce vendors. With 
respect to ease of set up and maintenance, there is provided, in accordance with one aspect of 
the present invention, a Multi-Vendor Internet Commerce System (MV-ICS) 202, which 
includes a centrally implemented Multi-Vendor Central Processing Unit (Multi-Vendor CPU) 
210 acting cooperatively with a centrally implemented Multi-Vendor Shared Datastores (MV- 
SD) 212. Using a variety of vendor-site I/O modules 220 and consumer-interface I/O modules 
216, the resources within the Multi-Vendor Shared Datastores (MV-SD) 212 may be shared by 
the plurality of vendor websites to relieve the individual vendor websites of the burden of 
setting up and maintaining some or all of the facilities of the Multi-Vendor Shared Datastores 
(MV-SD) 212 (such as the consumer database, the shopping cart facility, the checkout facility, 
and the like). However, logic in the Multi- Vendor Central processing unit (Multi-Vendor 
CPU) 210 of the Multi- Vendor Internet Commerce System (MV-ICS) 202 ensures that 
appropriate communication occurs between each vendor website and the Multi- Vendor Shared 
Datastores (MV-SD) 212 as well as the consumer via his or her browser. 




Detailed Description of the Preferred Embodiments 



From the perspective of the individual vendor website, the fact that the Multi-Vendor 
Shared Datastores (MV-SD) 212 is shared among many different vendor websites is 
substantially transparent, except for the additional benefits that are derived from sharing 




resources, as will be described hereinafter. Likewise, from the perspective of the consumer 
employing the Multi-Vendor Internet Commerce System (MV-ICS) 202 to make his or her 
selection and purchase, it is substantially transparent that the facilities that implement the 
shopping cart, the checkout procedure, as well as other shared resources (such as the gift 
registry or the sign-in procedure) are no longer implemented at individual vendor websites. As 
will be discussed later herein, the sharing of these resources also offer additional benefits and 
features to the consumers, which have been unavailable in the prior art paradigm. 

To facilitate discussion, Fig. 2 illustrates, in accordance with one aspect of the present 
invention, a Multi-Vendor Internet Commerce System (MV-ICS) 202, which includes the 
Multi-Vendor Central System (MV-CS) 204. MV-CS 204 represents the centrally 
implemented logic and data resources that may be shared by the plurality of vendor websites. 
Multi- Vendor Central System (MV-CS) 204 may also be utilized by the consumer terminal to 
conduct e-commerce transactions with the individual vendor websites vis-a-vis Multi-Vendor 
Internet Commerce System (MV-ICS) 202. As shown in Fig. 2, Multi- Vendor Internet 
Commerce System (MV-ICS) 202 includes a Multi-Vendor Central Processing Unit (Multi- 
Vendor CPU) 210 in communication with a Multi-Vendor Shared Datastores (MV-SD) 212. In 
general, Multi-Vendor CPU 210 and MV-SD 212 may be located at the same central location 
but they may also be dispersed among multiple sites that are interconnected through some 
network connection or through the Internet. Logically, however, they represent centrally 
implemented entities that are shared by the vendor websites and the consumer terminals and 
facilitate e-commerce therebetween. 

The Multi-Vendor Shared Datastores (MV-SD) 212 includes at least a consumer 
database, which tracks consumer profiles (i.e., shopper profiles) on behalf of the plurality of 
participating vendor websites. The information tracked by the consumer data base for each 
consumer may include, for example, the consumer personal information such as name, home 
address, phone number, payment method, and payment information (such as credit card 
information or deposit account information), as well as a unique shopper ID for uniquely 
identifying a consumer. The consumer profile for each consumer may also include a universal, 
cross- vendor shopping cart into which items selected from a plurality of vendors may be 
deposited. The consumer profile may also include other tools, registries, and lists such as the 
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universal, cross- vendor gift registry, the universal, cross- vendor remind-me registry, and the 
like. These registries are discussed in detail later herein. For convenience, an address book 
having therein address information for shipping purposes may also be included. 

The Multi-Vendor Shared Datastores (MV-SD) 212 may also include a vendor 
5 database, which tracks the participating vendor profiles and their websites. The vendor 

database may include the identity of the vendors who participate in the Multi-Vendor Internet 
Commerce System (MV-ICS) 202. Each vendor profile may also include additional 
information such as the vendor contact information, vendor branding graphics or sound, any 
shipping information, tax tables, and the like. The inclusion of the additional information is 
1 0 beneficial (although not required) as it renders the communication between the vendor websites 
and the Multi-Vendor CPU 210 more efficient since this additional information need not be 
□ transmitted from the vendor websites to the Multi- Vendor CPU 2 1 0 during, for example, the 

process of checking out wherein the Multi- Vendor CPU 210 calculates the invoice and creates 
the shipping bill for the items checked out. With the additional information kept centrally at 
HI! 15 the Multi-Vendor Shared Datastores (MV-SD) 212, only some unique vendor ID (which may 
.yy be included in the description of each item selected for the universal shopping cart and/or 

central checkout procedure) is required and any other information pertaining to the vendor may 

lac? 

CP then be obtained by cross-referencing the unique vendor ID against the vendor database. 

U± 

=p 

p Preferably but not necessarily, there is also included a product database, representing a 

20 database of products offered for sale by the participating vendors. Although the product 

database is optional, its inclusion within the Multi-Vendor Internet Commerce System (MV- 
ICS) 202 as part of the Multi- Vendor Shared Datastores (MV-SD) 212 renders the 
communication between the vendor websites and the Multi-Vendor CPU 210 more efficient as 
the full description of items selected by the consumers need not be transmitted from the vendor 
25 websites to the Multi-Vendor CPU 210 during, for example, the process of depositing an item 
into the centrally implemented universal shopping cart. With the centrally implemented 
product database in place, only some unique product ID is required and any other information 
pertaining to the selected item may then be obtained by cross-referencing the unique product ID 
against the product database. 



o 
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The Multi-Vendor Internet Commerce System (MV-ICS) 202 also includes a plurality 
of sets of consumer- interface I/O modules 216, each of which (e.g., 216a) may be utilized by a 
different consumer at a respective consumer terminal to perform transactions with the vendor 
websites vis-a-vis Multi-Vendor Internet Commerce System (MV-ICS) 202. There are also 
shown a plurality of sets of vendor-site I/O modules 220, each of which includes a set of tools 
to be implemented at a vendor website to allow that vendor website to employ the Multi- 
Vendor Internet Commerce System (MV-ICS) 202 to conduct e-commerce with consumers. 
As shown in Fig. 2, vendor-site I/O modules 220 are generally coupled to the Internet 230, as 
are consumer-interface I/O modules 216 and Multi-Vendor Central System (MV-CS) 240. 

Typically, these vendor-site I/O modules 220 may be implemented on the same page as 
that employed to display the items offered for sale. Each set of vendor-site I/O modules 220 
(such as 220a) may include one or more of the following: a central shopping cart link for 
dropping items selected from the vendor website into the universal shopping cart that resides at 
the Multi-Vendor Shared Datastores (MV-SD) 212, a central sign-in link for allowing a 
consumer to authenticate himself/herself with the Multi- Vendor Internet Commerce System 
(MV-ICS) 202, a central checkout link for allowing a consumer to quickly checkout an item 
selected from the vendor website, a gift link for allowing a consumer to place an item selected 
from the vendor website into the gift registry, a remind-me link for allowing a consumer to 
place an item selected from the vendor website into the remind-me registry. 

The universal shopping cart represents a cross-vendor shopping cart associated with the 
Multi-Vendor Internet Commerce System (MV-ICS) 202 and is a part the Multi-Vendor Shared 
Datastores (MV-SD) 212. The universal shopping cart is a persistent storage structure that is 
capable of holding items for purchases that have been selected by the consumer from a plurality 
of vendor websites until those items are checked out. The central checkout link represents a 
link that allows an item selected from the vendor website to be checked out using the central 
checkout facility associated with the Multi -Vendor Internet Commerce System (MV-ICS) 202. 
Another central checkout link exists in the shopping cart presentation page, which may be 
viewed by the consumer as part of the consumer interface I/O modules 2 1 6 that allow the 
consumer to checkout items from the universal shopping cart. The central gift link allows a 
consumer to place an item selected from the vendor website into the universal, cross-vendor 
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gift registry that exists at the centrally implemented Multi-Vendor Internet Commerce System 
(MV-ICS) 202 and is part of the MV-SD 212. Like the universal shopping cart, the universal 
gift registry is a persistent storage structure that is capable of holding items for purchases that 
have been selected by the consumer from a plurality of vendor websites until those items are 
5 checked out by the gift-giver (i.e., another consumer who is registered with the Multi -Vendor 
Internet Commerce System (MV-ICS) 202 who wishes to purchase one or more of the gifts in 
the gift registry for the gift registry holder). 

The remind-me registry is similarly another persistent storage structure associated with 

the Multi-Vendor Shared Datastores (MV-SD) 212 that is capable of holding items of interest 
10 that have been selected by the consumer from a plurality of vendor websites. Each item within 

the remind-me registry may be associated with a reminder action, which the consumer may set 
p to remind him/her to purchase the selected item(s) stored therein. Other vendor-site I/O 

modules are also possible, including different types of tools, registries and lists that are 
iD accessible by the participating vendor websites. By way of example, one of the registries may 

(iU 1 5 represent a bidding basket, which may also be another persistent storage structure associated 
ijj with the Multi-Vendor Shared Datastores (MV-SD) 212 that is capable of holding items of 

!_ interest that have been selected by the consumer from a plurality of vendor websites. Since the 

m bidding registry is associated with the Multi-Vendor Internet Commerce System (MV-ICS) 

202, and is more specifically one of the shared resources of the Multi-Vendor Shared 
^ 20 Datastores (MV-SD) 212, items in the bidding basket may be bid on by other vendors who may 

be able to offer a lower price, for example. 

Consumer- interface I/O modules 216 represent the tools and displays that allow the 
vendor websites and the consumer to communicate with one another via Multi- Vendor Internet 
Commerce System (MV-ICS) 202. In general, these consumer-interface links differ from the 

25 vendor-site I/O modules 220 in that they involve items and actions that are cross- vendor in 
nature. Further, these consumer-interface links may be implemented on any page that is 
viewable on the consumer's web site. The consumer-interface I/O modules 216 may include 
one or more of the following: a central sign-in link for allowing a consumer to authenticate 
himself/herself with the Multi-Vendor Internet Commerce System (MV-ICS) 202, a view gift 

30 registry link for allowing the consumer to inspect the content of his gift registry at the Multi- 
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Vendor Internet Commerce System (MV-ICS) 202, a view account link for allowing a 
consumer to view his or her account with the Multi-Vendor Internet Commerce System (MV- 
ICS) 202 (including, for example, viewing past invoices and editing the consumer 
personal/payment/shipping data), a view other gift registries link for allowing a consumer to 
view gift registries of other consumers that have registered with the Multi-Vendor Internet 
Commerce System (MV-ICS) 202 (so that he/she can make a gift purchase for the gift registry- 
holder, for example), a view universal shopping cart link so that the consumer may view the 
content of his/her universal shopping cart stored with the Multi- Vendor Internet Commerce 
System (MV-ICS) 202, and a checkout link (typically but not necessarily implemented on the 
page that displays the universal shopping cart) for allowing the consumer to check out one or 
more items stored in the universal shopping cart, and the like. The above list is only 
illustrative and not exhaustive and therefore should not be viewed as limiting the scope of the 
invention. 

In the described embodiment, Multi-Vendor CPU 210 includes one or more of the 
following: gift registry logic, shopping cart logic, sign-in logic, checkout logic, and 
conveyance logic. Some of the functions that may be performed by these logic units include 
access control and communication of the appropriate data in the Multi-Vendor Shared 
Datastores (MV-SD) 212 to the consumer terminals and/or the web sites. Access control is 
important for confidentiality and security reasons. By way of example, although the universal 
shopping cart may contain items from multiple vendors, it is generally desirable to convey to a 
vendor only information pertaining to items from that vendor's website when the consumer 
checks out the items from the shopping cart. 

With respect to the various logic units within Multi-Vendor CPU 210, gift registry logic 
represents the logic for receiving items from the various websites that have been selected by 
the consumers to be placed into the various gift registries. Gift registry logic also permits the 
consumer to search gift registries, view, add an item to, remove an item from, or make a 
purchase from a gift registry. Since both the gift registry and the gift registry logic are 
implemented with the Multi-Vendor Internet Commerce System (MV-ICS) 202, they are 
typically cross-vendor in nature. Likewise, shopping cart logic represents the logic for 
receiving items from the various websites that have been selected by the consumers to be 
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placed into the universal shopping cart. Shopping cart logic also permits the consumer to view, 
add an item to, remove an item from, or make a purchase from the universal shopping cart. 

Sign-in logic represents the logic for presenting the authentication page to the consumer 
and performing the authentication. For a consumer who is new to the Multi -Vendor Internet 
Commerce System (MV-ICS) 202, sign-in logic also performs the function of registering the 
new consumer and collects personal/payment/shipping data to be stored in the consumer 
profiles in the consumer database (part of MV-SD 212). Checkout logic represents the logic 
for checking out items selected for purchase. The items may be selected directly from the 
website and checked out via the checkout logic within Multi- Vendor CPU 2 1 0 or from the 
universal shopping cart. Checkout logic includes intelligence for calculating tax, shipping, 
subtotals, totals, and the like using data from such sources as the selected items, the consumer 
database, merchant database (and optionally the product database), and so on. Checkout logic 
also performs the function of preparing the invoice, presenting the invoice to the consumer, 
obtaining any necessary and/or additional information pertaining to payment/shipping, and 
receiving the approval from the consumer for completing the transaction. 

In the described embodiment, conveyance logic represents the logic for communicating 
the information to each vendor about the item(s) purchased from that vendor, the amount of the 
purchase, and any shipping information. If the Multi-Vendor Internet Commerce System (MV- 
ICS) 202 acts as the merchant of record, the consumer's credit card or account may be debited 
by the checkout logic. On the other hand, if the merchants of record are the vendors 
themselves, conveyance logic may also transmit the payment data (e.g., credit card 
information) to the vendors so that the amount of purchased from each vendor may be debited. 

In this manner, the Multi-Vendor Internet Commerce System (MV-ICS) 202 allow 
vendors who are otherwise unrelated and/or totally unknown to one another to share an Internet 
commerce system. As long as a vendor registers its profile with the centrally implemented 
Multi- Vendor Central System (MV-CS) 240 and its website can communicate to the vendor- 
site I/O modules 220 to transmit data pertaining to the items selected by the consumer for the 
universal shopping cart and/or checkout using the Multi -Vendor Internet Commerce System 
(MV-ICS) 202 facility, such vendor can be e-commerce enabled, i.e., can sell their 
merchandise through the Internet. In one embodiment, the central checkout link and the central 
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shopping cart link may be implemented simply as HTML links from each item of merchandise. 
When invoked, the central checkout link or the central shopping cart link simply sends the 
information pertaining to the item of merchandise selected, along with the consumer identity, 
to the Multi- Vendor Central System (MV-CS) 240. The Multi- Vendor Internet Commerce 
System (MV-ICS) 202 then interacts with the consumer through the consumer terminal and the 
consumer- interface I/O modules 216 to facilitate the shopping cart experience and the checkout 
process. In one embodiment, if the user identity is unknown, the user identity may be 
ascertained using the sign-in facility from the Multi -Vendor Internet Commerce System (MV- 
ICS) 202 itself. 

To further facilitate an appreciation of the features and advantages of the Multi-Vendor 
Internet Commerce System (MV-ICS) 202 of the present invention, Fig. 3 illustrates, in one 
exemplary implementation, a Multi- Vendor Internet Commerce System (MV-ICS) system 300, 
which includes a centrally implemented Multi -Vendor Central System (MV-CS) 240, which 
includes a Multi-Vendor CPU 210 and a Multi-Vendor Shared Datastores (MV-SD) 212. As 
mentioned earlier, Multi-Vendor Shared Datastores (MV-SD) 212 includes at least a consumer 
database 304, a vendor database 306, as well as. an optional product database 308. To simplify 
discussion, only the checkout logic 310 and the shopping cart logic 312 of Multi -Vendor CPU 
210 are shown in Fig. 3 although it should be understood that other types of logic modules may 
be implemented within Multi-Vendor CPU 210. 

With reference to Fig. 3, Multi-Vendor Central System (MV-CS) 240 is shown coupled 
to the Internet 230. Also shown coupled to Internet 230 are three exemplary vendor websites 
X, Y, and Z, representing the websites that implement the product offerings of the three 
independent vendors. In the example of Fig. 3, vendor X represents a vendor who has an 
existing e-commerce website and existing proprietary shopping cart facility and checkout 
facility similar to those described in connection with Fig. 1. For this example, vendor Y 
represents a vendor who has their catalog of product offerings hosted by the Multi-Vendor 
Internet Commerce System (MV-ICS) network, while vendor Z represents a vendor who has 
not or has no desire to develop a catalog and merely wishes to have the ability to sell items 
described in simple linkable pages of text and/or graphics (e.g., such as an HTML page). 
Techniques for enabling these vendors to offer their products for sale through the Multi- Vendor 
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Internet Commerce System (MV-ICS) 300 and to allow consumers of their products to utilize 
the cross vendor universal shopping cart and checkout logic of Multi-Vendor Central System 
(MV-CS) 240 are discussed subsequently herein. 

Also shown in Fig. 3 is a client browser 318, representing the consumer interface 
through which a consumer may interact with the product offering pages provided by vendor 
website X, vendor website Y, and vendor website Z, as well as to perform actions such as sign- 
in/registration to the Multi- Vendor Internet Commerce System (MV-ICS) system, to view the 
product offerings offered by the vendors and select items for the shopping cart and/or checkout, 
to view the universal shopping cart that contains products from multiple vendors, and to 
perform the checkout on the products selected at one of the product offering pages viewed on 
client browser 318. The exemplary product offering pages associated with vendors X, Y, and Z 
are shown as pages 320, 322, and 324. 

A page 326 is also shown, representing the page for displaying the universal shopping 
cart transmitted from Multi- Vendor Central System (MV-CS) 240 when the consumer either 
drops an item from one of the pages 320, 322, or 3 24 into the universal shopping cart or when 
the consumer requests to view the contents of the universal shopping cart by clicking on an 
appropriate button. A checkout page 328 is shown, representing the page provided by Multi- 
Vendor Central System (MV-CS) 240 when the consumer selects to checkout by invoking the 
central checkout link associated either with the universal shopping cart display page 326 or one 
of the items listed in the product pages 320, 322, or 324. There is also shown a sign- 
in/registration page 330, representing the page employed by the consumer to authenticate 
himself with the Multi- Vendor Internet Commerce System (MV-ICS) 300 or to sign-in as a 
new consumer to register with the Multi- Vendor Internet Commerce System (MV-ICS) 300. 

In operation, when a consumer, through client browser 318, enters a universal resource 
locator (URL) associated with vendor X, the X product page 320 may be viewed on client 
browser 318 (typically, after going through the introductory pages and/or some sign-in process 
which vendor website X may require and is irrelevant to the purpose of the invention herein). 
On X product page, there may be already implemented a local shopping cart link and a local 
checkout link, which allows the consumer to have access to a local shopping cart that is 
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specific to vendor X and to checkout through vendor X in the manner discussed with prior art 
Fig. 1. 

However, the presence or absence of the local shopping cart link and the local checkout 
link is irrelevant to the present invention. In fact, one of the advantages of the inventive Multi- 
5 Vendor Internet Commerce System (MV-ICS) 300 is its ability to work with any type of vendor 
website irrespective of the level of e-commerce facility that is present or absent. As long as a 
central shopping cart link can be associated with an item of merchandise to transmit a unique 
description of that item of merchandise (or a more complete description which includes the 
price and merchant identification), the vendor can be selling that item through the Internet and 
10 receive shipping and payment data pertaining to the purchase of that item from the Multi- 
Vendor Internet Commerce System (MV-ICS) 300 (by a non-web method such as fax or mail 
if desired). 

9 

jjg To enable vendor X to participate in the Multi-Vendor Internet Commerce System 

jjjj (MV-ICS) 300, each item offered for sale by vendor X on X product page 320 may be provided 

M 15 with a central shopping cart link 330, which represents a link for passing certain information 

yy 

a pertaining to the item (and preferably the consumer identification) to the Multi-Vendor Central 

System (MV-CS) 240 when the central shopping cart link associated with that item is invoked. 
By way of example, if X product page sells light bulbs, the invocation of a central shopping 
q cart link 330 associated with a 75- watt light bulb would cause the description of the 75 -watt 

^ 20 light bulb to be transmitted to Multi-Vendor Central System (MV-CS) 240 via the Internet 230. 
With reference to Fig. 4, the receipt by the Multi-Vendor Central System (MV-CS) 240 of the 
command to drop a selected item into the universal shopping cart is shown as step 402 of Fig. 
4. 

If the consumer employs an Internet terminal through which he has earlier registered 
25 with Multi-Vendor Central System (MV-CS) 240 or interacts with Multi-Vendor Central 
System (MV-CS) 240, there is typically cached at that Internet terminal some persistent 
information pertaining to the consumer, which may be passed along to Multi -Vendor Central 
System (MV-CS) 240 when the central shopping cart link is invoked on a browser displayed on 
that Internet terminal. In the current technology, such persistent consumer information may be 
30 stored in the form of a cookie that resides at the client terminal and is passed along with the 
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product identification to Multi- Vendor Central System (MV-CS) 240 when the central 
shopping cart link associated with an item is invoked. 

If the consumer's cookie is present (as ascertained by the Multi- Vendor Central System 
(MV-CS) in step 404 of Fig. 4), the consumer information within the cookie is employed to 
ascertain the identity of the consumer who has requested that the selected item be dropped into 
his/her universal shopping cart. On the other hand, if there is no user information present (i.e., 
no cookie), the transmission of a command to drop an item into a universal shopping cart (or to 
checkout a selected item using the Multi -Vendor Internet Commerce System (MV-ICS) 300) 
will cause Multi-Vendor Central System (MV-CS) 240 to send a sign-in/registration page to 
client browser 3 1 8 to either authenticate consumer with the Multi-Vendor Central System 
(MV-CS) 240 (if the consumer already registered earlier but on another Internet terminal) or to 
register if the consumer is not one who has previously registered with the Multi-Vendor 
Internet Commerce System (MV-ICS) 300. The transmission of the sign-in/registration page 
330 and the receipt of the sign-in/registration information is shown via path 340 and 342 in 
Fig. 3. Note that the sign-in/registration is performed by the Multi-Vendor Central System 
(MV-CS) 240 and requires no action on the part of the vendor website. In other words, there is 
no need to implement a sign-in/registration facility in the vendor website with the Multi- 
Vendor Internet Commerce System (MV-ICS) 300 to enable e-commerce. On the Multi- 
Vendor Central System (MV-CS) 240 side, this sign-in/registration step is shown as step 406 
of Fig. 4. 

At any rate, the consumer identity is ascertained by the Multi-Vendor Central System 
(MV-CS) 240, either through a cookie or by the sign-in/registration procedure. Once the 
consumer identity is ascertained, the Multi-Vendor Central System (MV-CS) 240 obtains the 
universal shopping cart from consumer database 304 or another database that stores the 
universal shopping cart of the identified consumer. From the perspective of the Multi-Vendor 
Central System (MV-CS) 240, step 408 shows the step of obtaining the universal shopping cart 
for the identified consumer from the consumer database. 

In one embodiment, it may be recognized that although the universal shopping cart is 
cross- vendor and therefore does not need to be branded with any vendor identification, it may 
be less confusing for the consumer if the shopping cart is provided with the branding 
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information associated with the last vendor from whom the consumer selected an item to be 
placed in the universal shopping cart. By way of example, when a consumer selects an item 
offered for sale by vendor X s it is less disorienting for the consumer if the. universal shopping 
cart page that displays the universal shopping cart reflects in some manner the fact that the 
consumer has just selected an item from vendor X to be placed into the universal shopping cart. 
However, it is contemplated that additional branding and/or advertising is not precluded; the 
point is to identify, in one embodiment, in some manner at the universal shopping cart the 
vendor from whom the consumer has just selected an item. 

For this reason, the vendor database 306 may be consulted, using the vendor 
information that is associated with the items selected to be dropped into the universal shopping 
cart, for any branding information (such as graphics or sound). This step is shown in Fig. 4 as 
step 410. Furthermore, the selected item that is transmitted from X product page 320 to Multi- 
Vendor Central System (MV-CS) 240 is then added to the universal shopping cart (step 412 of 
Fig. 4). Preferably, the universal shopping cart and its content are then presented to the 
consumer via client browser 318 in a suitable display page (step 414 of Fig. 4). Depending on 
the level of details of the information stored in the universal shopping cart on Multi-Vendor 
Central System (MV-CS) 240, it may be necessary to consult product database 308 to obtain an 
adequate level of details of the products in the universal shopping cart prior to displaying the 
' shopping cart page 326 to the consumer via client browser 318. 

If the consumer wishes to browse further, he may click on a return-to-browsing link 346 
which implements a link to the last product page displayed before the consumer selects to drop 
an item into the universal shopping cart (steps 416 and 418 of Fig. 4). Subsequently, the 
consumer may select additional items from the same vendor or even from different vendors 
who have registered with the Multi- Vendor Internet Commerce System (MV-ICS) 300 to add 
additional items into the universal shopping cart at Multi- Vendor Central System (MV-CS) 
240. Note that since the universal shopping cart is implemented independently of the website 
of the vendors, it is possible to have one single shopping cart that contains items from multiple 
vendors from multiple websites. 

While viewing the shopping cart page 326, the consumer may also invoke the central 
checkout link 348 to initiate the checkout process via Multi-Vendor Central System (MV-CS) 
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240. Invoking the central checkout link 348 causes checkout logic 3 10 to begin processing the 
items slated for checkout within the universal shopping cart. In some cases, the consumer may 
wish to hold one or more of the items instead of checking them out, e.g., for further 
comparison shopping or other purposes. Once Multi-Vendor Central System (MV-CS) 240 
receives the instruction to begin checking out items (step 502 of Fig. 5), the cost for each item 
to be checked out is calculated from the universal shopping cart and shared databases of Multi- 
Vendor Central System (MV-CS) 240 (step 504 of Fig. 5). The cost of each item may be 
influenced by tax, shipping, any discount or promotion, and the like. 

Thereafter, checkout logic 310 of Multi-Vendor Central System (MV-CS) 240 may 
present a checkout page 328, which shows the invoice to consumer along with any shipping 
data and/or payment data obtained from the consumer profile in consumer database 304 (step 
506 of Fig. 5). The consumer then has the option of accepting the default information or may 
edit to, for example, provide another address to ship to or use a different credit card than the 
default credit card. Once the consumer authorizes the purchase (step 508 of Fig. 5) and the 
authorization is received at Multi-Vendor Central System (MV-CS) 240, Multi-Vendor Central 
System (MV-CS) 240 may then convey the correct portion of the invoice to the appropriate 
vendor(s). In one embodiment, the ship data (e.g., the item description, the name of the 
recipient and the shipping address) and the payment data (e.g., the information pertaining to the 
account information to be charged to the consumer) is forwarded to the vendor to allow the 
vendor to perform the actual charging of the consumer's account (steps 510 and 512 of Fig. 5). 
Preferably but not necessarily, the conveyance to each vendor may be encrypted. 

In one advantageous embodiment, it is contemplated that the conveyance of the portion 
of the invoice to each of the vendors may be done using a non-web paradigm (such as fax, 
phone, or mail) to maximize security. The use of a non-web method to convey the ship data 
(and the payment data) also permits vendors who have not equipped their websites to receive 
these types of data to participate in e-commerce using widely available and proven settlement 
techniques (such as manually entering the credit card information received by phone/fax into a 
point-of-sale terminal) and manually ship the items using the ship data received via phone or 
fax or mail. 
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Still further, the Multi-Vendor Internet Commerce System (MV-ICS) 300 may act as 
the merchant of record and may proceed to charge the price of the invoice against the account 
of the consumer so that no account information needs to be transmitted to the vendors. This is 
another advantageous arrangement since it minimizes the security and fraud risks involved in 
transmitting sensitive consumer payment data (e.g., credit card information) and storing such 
information at multiple vendor websites. In this case, the sensitive data is kept at the Multi- 
Vendor Central System (MV-CS) 240 and the access thereto is guarded by the Multi -Vendor 
CPU 210. In this case, only the consumer's shipment information along with the identification 
of the items to be shipped need to be transmitted to the vendor (step 514). Since there is less 
concern with confidentiality (due to the absence of sensitive payment information), this 
information can be conveyed to the vendors using web-based paradigm if desired or by a non- 
web paradigm if appropriate. 

Fig. 6 illustrates, in accordance with one embodiment of the present invention, an 
exemplary sign-in/registration process, which may be initiated by either the Multi-Vendor 
Central System (MV-CS) 240 or by the consumer upon clicking on link on the vendor's web 
page (or any webpage that may link such a request to Multi-Vendor Central System (MV-CS) 
240. In general, a consumer may request to be authenticated/signed-in at any time after 
accessing a vendor website that is part of the Multi- Vendor Internet Commerce System (MV- 
ICS) 202. Early authentication (or sign-in) is advantageous since it allows the Multi- Vendor 
Central System (MV-CS) 240 to customize the display to the identified customer's preferences 
and settings sooner in the shopping experience, which is beneficial from an ease-of-use 
standpoint. 

However, certain events may also cause the Multi- Vendor Central System (MV-CS) 
240 to initiate the sign-in/registration procedure. By way of example, the selection of an item 
on a product offering page for adding to the universal shopping cart may cause the Multi- 
Vendor Central System (MV-CS) 240 to initiate the sign-in/registration procedure if no user 
information can be ascertained to determine in the user database the identity of the user who 
has just selected the item to be added to a universal shopping cart. This is because the Multi- 
Vendor Central System (MV-CS) 240 needs to know the identity of the consumer in order to 
obtain the right universal shopping cart to add the selected item to. As mentioned earlier, the 
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absence of a cookie associated with the Multi-Vendor Central System (MV-CS) 240 typically 
signifies that the consumer is either new (unregistered) or has not employed this Internet 
terminal to conduct Internet commerce transaction via the Multi-Vendor Internet Commerce 
System (MV-ICS) 202. 

With reference to Fig. 6, the sign-in/registration process begins with the presentation of 
the sign-in/registration page to the consumer at the consumer's Internet terminal in step 602. In 
step 604, the authentication data is received from the consumer. In step 606, the consumer is 
asked whether the consumer is a new (i.e., not registered) consumer or a registered consumer 
who wishes to employ the Multi-Vendor Internet Commerce System (MV-ICS) again to 
conduct the Internet commerce transaction. If the consumer is a new, unregistered consumer, 
the Multi-Vendor Central System (MV-CS) proceeds to step 608 to initiate the registration 
process for the new consumer. On the other hand, if the consumer indicates that he/she is a 
consumer already registered in the consumer database, the method proceeds to step 610 
wherein the consumer is authenticated (e.g., using a shopperlD/password procedure or some 
biometrics procedure). 

If not authenticated, the method returns to step 602 to begin the authentication/sign-in 
process again. On the other hand, if the consumer is authenticated as a previously registered 
consumer or as a new consumer (via step 608), the method proceeds to optionally set a cookie 
at the consumer's Internet terminal (step 612). Thereafter, the consumer data is obtained from 
the consumer database for the purpose of correlating the identified consumer with the action 
that requires his/her identity. 

So far, the discussion has mostly revolved around vendor websites that are catalogs or 
databases in the traditional sense. In one embodiment, a vendor may be e-commerce enabled 
by simply furnishing a database of product information (which includes description and price) 
as well as product IDs. Using a data driven page having the vendor-site I/O modules 220 
implemented thereon and the links pertaining thereto formed from the items displayed, a 
vendor can very quickly become e-commerce enabled. As the consumer flips the "pages," the 
displayed item(s) change, which cause the data-driven portion of the link(s) that underlie the 
vendor-site I/O module to change. To further elaborate, the data-driven portion of the links 
represent the description of the item being displayed, the price, the page to return to after the 
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shopping cart is viewed, and the like. Other pieces of information in the link (such as the 
destination for the link) may stay substantially unchanged. 

Furthermore, there is no need to have a database to participate in e-commerce given the 
present invention. As long as a link can be implemented on a page to link to an item to be 
offered for sale (and the description/price/merchant identification can be ascertained from a 
combination of information contained in the link and the databases at Multi-Vendor Central 
System (MV-CS) 240), it is irrelevant whether the underlying data is implemented as a 
database or simply raw HTML pages. In a simple example, an HTML with a linkable word, 
image, or any area of the screen within the page boundaries may be pasted with HTML code 
linking that linkable portion to the Multi-Vendor Central System (MV-CS) 240. As long as the 
underlying link is provided with description information pertaining to the item offered for sale 
to be transmitted to the Multi-Vendor Central System (MV-CS) 240 and the combination of 
information contained in the link and the databases at Multi- Vendor Central System (MV-CS) 
240 can yield the selected item's identification, its price, its vendor, the shipping charges and 
practices of its vendor, the Multi-Vendor Internet Commerce System (MV-ICS) 202 can handle 
consumer authentication/registration, shopping cart implementation, and checkout and send the 
shipping data (and optionally payment data) to the vendor for shipping and settlement, using 
either a web-based method or non web-based methods. 

Fig.7 illustrates a representative HTML snippet 700 encoded in an exemplary vendor 
page to facilitate a purchase in accordance with an embodiment of the invention. It should be 
noted that the snippet 700 can be used for an "Add to Cart" transaction as well as, for example, 
"Add- to Wish List" or an "Add to Gift Registry" transaction. When a user clicks on, for 
example, an "Add to Cart" button, the snippet 700 (which has typically been encoded by the 
merchant- vendor) is invoked. A message packet is then sent on to the Multi- Vendor Internet 
Commerce System (MV-ICS) 202. In one embodiment, the message packet includes such 
information as: MerchantID, ProductName, SKU#, Quantity, Price, and Return URL. These 
pieces of data (in the form of the message packet) taking the form of an HTTP request are 
transmitted over, for example, the Internet from the user's browser to the Multi- Vendor 
Internet Commerce System (MV-ICS) 202. Typically, in response to the received HTTP 
request, the Multi-Vendor Internet Commerce System (MV-ICS) 202 displays a particular 
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document, or page, on the user's browser. In the case of the "Add to Cart" transaction, the 
user's personal shopping cart with the particular product identified by the snippet 700 is 
included therein. 

As an example, the Add to Cart snippet 700 includes HTML code and corresponding 
5 data fields. In the illustrated example of Fig. 7A, the code section 

"http://www.catalogcity.com/" represents the destination address of the server implementing 
the Multi- vendor Central System (MV-CS). The code section represents 
"external/addprod.cfm" represents to command to the MV-CS server to process this HTML 
code in accordance to the fields specified therewith. The code section "ccpid=754369" 
1 0 represents the code section that includes the vendor's merchant ID to uniquely identify the 
vendor. The code section "cmd=s" represents the command to add the item associated with 
r =i this HTML code to the shopping cart. Note that this code section may also read, for example, 

"cmd=g" (as shown in Fig. 7B) to represent the command for adding the item to the gift 
y3 registry. The code section 

m 1 5 "rtn=http%3 A%2F%2Fwww%2Eamazon%2Ecom%2Fexec%2Fobidos% 

2FASIN%2F045 11911 45%2Fo%2Fqid%3D930776352%2Fsr%3D2%2D 1 %2F002%2D02349 
£ _ 99%2D7522204" represents the code section that includes the return address of the page 

fp associated with the selected item, the code section "sku=24372" represents the code section 

J! that includes the SKU number of the item of merchandise (which is unique to each item of 

P 20 merchandise of the vendor). The code section "qty=l" represents the code section that includes 

f i 

the quantity selected. The code section "name=Ayn%20Rand%3A%20Atlas%20Shrugged" 
that includes the name of the item of merchandise. The code section "price=7.19" represents 
the code section that includes the price of the item selected. The code section "ccsyn=l 1114" 
represents the code section that includes the merchant interface ID, e.g., the interface that 
25 includes the branding associated with the vendor to more quickly associated the item(s) viewed 
in the universal shopping cart with the vendor from whom the item(s) were bought. 

Fig. 8 is a representative merchant input form 800 used to create the snippet 700 in 
accordance with an embodiment of the invention. The input form 800 includes an item code 
input field 802 used, for example, to input a particular product SKU. An item name file 804 is 
30 used to optionally input the product's name or other identifying nomenclature. A price field 
806 is used to input the item's price while a return URL field 808 is used to input the return 
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location of the vendor. It should be noted that the form of the input form 800 can be any form 
deemed appropriate for the application at hand. 

Fig. 9 illustrates a representative transactional architecture 900 in accordance with an 
embodiment of the invention. The architecture 900 includes a Multi-Vendor Central System 
(MV-CS) 902 arranged to provide a multi- vendor shopping cart, a gift registry, gift certificates, 
email capabilities such as email reminders, coupon and promotion support, as well as single 
sign on capability and merchant editing tools. It should be noted that the Multi- Vendor Central 
System (MV-CS) 902 is one implementation of the Multi-Vendor Central System (MV-CS) 
202 described in Fig. 2. The Multi- Vendor Central System (MV-CS) 902 is coupled to various 
online e-commerce vendors 904 providing such features as gift registry, coupons, gift 
certificates, etc. Various portal partners 906 such as Yahoo, ShopNow, provide direct links 
between particular portals that provide various goods and services to the Multi-Vendor Central 
System (MV-CS) 902 (and in turn the consumers 908). In one embodiment, a combined 
customer database 910 is provided that accumulates selected consumer information useful in 
providing consumer profiles for such things as selectively mailing only those catalogs most 
likely to be appreciated by those consumers receiving them. 

Referring now to Fig. 10, an exemplary product page 1000 representative of the vendor 
X product page 320 is shown. The product page 1000 includes an Add to Cart button 1002 as 
well as buttons 1 004 and 1 006 corresponding to a "My Gift" and "My Buy". 

Fig. 1 1 shows an exemplary web page for a vendor whose catalog of product offerings 
is hosted by the Multi-Vendor Internet Commerce System (MV-ICS) network as represented by 
product page 322. 

Fig. 12 illustrates an exemplary web page for a vendor who has not or has no desire to 
develop a catalog, yet is e-commerce enabled as represented by the product page 320. 

Fig. 13 illustrates the universal shopping cart as represented by page 326. 

Fig. 14 illustrates an exemplary gift registry in accordance with an embodiment of the 
invention. 
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Fig. 1 5 illustrates an exemplary web page presented by the Multi-Vendor Central 
System (MV-CS) in accordance with an embodiment of the invention. 

Fig. 16 illustrates an exemplary shopping cart web page associated with a vendor type 
X in accordance with an embodiment of the invention. 

5 Fig. 1 7 illustrates an exemplary merchant input in support of a "My Stores" 

implementation. 

Fig. 1 8 illustrates, in accordance with one embodiment of the invention, the steps taken 
by a vendor to become e-commerce enabled through the use of the inventive Multi-Vendor 
Internet Commerce System (MV-ICS). Prior to the steps herein, it should be understood that 
10 the vendor needs to register with the Multi- Vendor Internet Commerce System (MV-ICS) 
P operator, which may be performed using any web-based or non- web-based method, 

m Registration permits the Multi- Vendor Internet Commerce System (MV-ICS) operator to have 

knowledge, at minimum, of the vendor and its contact information for the purpose of 
py conveying data pertaining to items selected for sale thereto. In step 1802, the vendor (or a 

yyj 15 service that it contracts) provides an electronically linkable presentation of the items for sale. 
P As mentioned earlier, this may be in the form of HTML pages or may be more elaborate 

P s database driven displays. Furthermore, the vendor may elect to have his paper catalogs 

pi 

=p scanned in and converted to an electronic format and then have electronic database (or HTML 

Q 

= 3 pages) hosted, which eliminates even the need for the vendor to be knowledgeable about the 

20 Internet and its enabling technologies. 

In step 1 804, the vendor obtains the format of the vendor-site I/O module, which is 
capable of being linked to the items to be offered for sale and provides at least the identity of 
the merchandise item selected to the Multi-Vendor Central System (MV-CS). Depending on 
the amount of information already furnished to the Multi-Vendor Internet Commerce System 

25 (MV-ICS), the amount of information necessary to uniquely identify the merchandise item 
selected may vary widely. At one end of the scale, databases centrally implemented at the 
Multi-Vendor Central System (MV-CS) may allow the vendor to simply send a unique 
identification code associated with the selected item through the vendor-site I/O module to the 
Multi-Vendor Central System (MV-CS) and all information pertaining to the vendor profile 

30 and the product information can be derived therefrom using the unique identification code as a 
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search key into the centrally implemented databases at the Multi-Vendor Central System (MV- 
CS). At the other end of the scale, there may be little information at the centrally-implemented 
Multi-Vendor Central System (MV-CS) and the link may be employed to furnish all textual 
description, graphics, and price information pertaining to the selected items, along with as 
much of the vendor profile as necessary for the Multi-Vendor Central System (MV-CS) to 
perform the checkout process (which includes calculating the cost correctly for the item 
selected for purchase). The artisan will recognize that there are variations between these two 
extremes. 

In step 1 806, the vendor-site I/O module and the item associated therewith are linked 
together. Linking may be made on an item-by-item basis or may be made for an entire page, 
and an item or items selected for action by the Multi-Vendor Internet Commerce System (MV- 
ICS) on the vendor page will have its identification information sent to the Multi- Vendor 
Central System (MV-CS). In step 1 808, the vendor renders the linkable presentation of the 
items for sale, including the vendor-site I/O modules implemented thereon, available to the 
consumer via the Internet upon request. In step 1810, the vendor receives the vendor-specific 
information from the Multi- Vendor Central System (MV-CS), which includes at least 
information to identify the item(s) purchased by a consumer from this vendor. As mentioned 
earlier, some of the personal data pertaining to the consumer may be made anonymous in one 
embodiment to provide privacy for the consumer. In a typical situation, the vendor is provided 
with the identification of the item(s) purchased, the identity of the purchaser and the shipping 
address, the chosen shipping method and any other special shipping instructions. If the vendor 
acts as the merchant of record, payment data is also received. If the Multi-Vendor Internet 
Commerce System (MV-ICS) acts as the merchant of record, the Multi-Vendor Internet 
Commerce System (MV-ICS) may charge the consumer's account (or credit card). In this latter 
case, the vendor may only receive an accounting statement and settlement from the Multi- 
Vendor Internet Commerce System (MV-ICS) (either concurrently with the transmission of the 
shipping data or at a later date). As mentioned, there is no need to convey the shipping data 
and/or payment data via a web-based method (although such may be preferred by some 
vendors, particularly using encrypted technologies). The use of non-web methods for 
conveying the shipping and/or payment data to the vendor advantageously renders the Multi- 
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Vendor Internet Commerce System (MV-ICS)-based e-commerce enabling technique fully 
compatible with contemporary vendors who are not web-enabled. 

Fig. 1 9 illustrates, in accordance with one embodiment of the present invention, the 
steps taken by the operator of the Multi-Vendor Internet Commerce System (MV-ICS) to offer 
5 e-commerce capabilities to a plurality of vendors who may be completely independent of one 
another but are registered to share the shared resources of the Multi- Vendor Central System 
(MV-CS). Prior to the steps herein, it should be understood that the vendor needs to register 
with the Multi- Vendor Internet Commerce System (MV-ICS) operator, which may be 
performed using any web-based or nonweb-based method. In step 1902, the format of the 
10 vendor-site I/O module is provided to the vendor to allow the vendor to create links to the 
merchandise items presented (e.g., displayed on a page). 

In step 1904, the Multi-Vendor Internet Commerce System (MV-ICS) operator receives 
L J3 at the Multi -Vendor Central System (MV-CS) through the vendor-site I/O module information 

fU pertaining to an item selected by the consumer for action (e.g., from merchandise display page). 

15 In step 1906, the Multi-Vendor Central System (MV-CS) interacts with the consumer via the 
consumer-interface I/O module to perform the action requested by the consumer. Some of 
yf| these actions, which are performed by the Multi-Vendor Internet Commerce System (MV-ICS) 

'j* independent of the individual vendor websites after the identification of the selected item is 

P ascertained, include the cross- vendor authentication/registration procedure (if the consumer has 

□ 

20 not already signed in prior to item selection for action), cross- vendor registries procedures, the 
cross-vendor shopping cart procedure, and the cross-vendor checkout procedure. 

If the consumer wishes to make a purchase (step 1 908), the Multi-Vendor Central 
System (MV-CS) may calculate and present an invoice for the item(s) selected for purchase 
and present the invoice, via the consumer-interface I/O module in step 1910, to the consumer 

25 for approval. In step 1912, the Multi-Vendor Central System (MV-CS) may obtain 

payment/shipping data from the consumer database and present such payment/shipping data, 
via the consumer-interface I/O module, to the consumer for edit/approval. If approved, the 
Multi- Vendor Central System (MV-CS) then provides vendor-specific information to each 
vendor involved (step 1914), which includes at least information to identify the item(s) 

30 purchased by a consumer from the vendor. The vendor- specific information has been 
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described earlier in connection with step 1810 of Fig. 18. Thereafter, the Multi-Vendor Central 
System (MV-CS) may either continue to interact with the consumer, via the consumer- interface 
I/O module, to continue servicing the user's Multi- Vendor Internet Commerce System (MV- 
ICS) related requests or allow the user to return to the vendor's website(s) to continue browsing 
(step 1916). 

As mentioned earlier, the inventive Multi- Vendor Internet Commerce System (MV- 
ICS) renders it possible for vendors to become e-commerce enabled without any undue 
investment in e-commerce infrastructures since the centrally-implemented Multi-Vendor 
Central System (MV-CS) performs many of the functions earlier required of each vendor 
website in its interaction with the web consumers. As long as a linkable presentation of the 
items to be sold (in either text, graphics, sound, or any other communication medium) can be 
provided to the consumer via the Internet, a link (in the form of vendor-site I/O modules) can 
be attached to the linkable presentation to allow the Multi -Vendor Central System (MV-CS) to 
obtain the information pertaining to the item(s) offered for sale and to allow the Multi- Vendor 
Internet Commerce System (MV-ICS) to interact with the consumer to perform the cross- 
vendor consumer registration procedure, the cross-vendor shopping cart procedure, and the 
cross-vendor checkout procedure. 

The act of providing the linkable presentation (e.g., pages, emails, banners, etc.) of 
items to be sold may be performed by the vendor or may be performed by a hosting service 
which converts the images and text of the items to be sold (e.g., in paper form) to an electronic, 
linkable format (such as HTML). Likewise, the act of attaching a suitable link to the linkable 
presentation may also be performed by someone other than the vendor, e.g., by the hosting 
service, a web-design firm, or any suitable person. Since the link may be implemented as a 
data-driven template of HTML codes, the invention advantageously simplifies even this aspect, 
rendering it capable of being performed by relatively unsophisticated (technically speaking) 
persons. 

Once the Multi- Vendor Central System (MV-CS) is furnished with the price of the 
item(s) offered for sale (as well as any other cost-related information such as the tax table, the 
discount schedule, and shipping/handling charges, if any, for the vendors) and the vendor 
contact information, the Multi-Vendor Central System (MV-CS) can perform the checkout 
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procedure on behalf of each vendor and convey shipping information to each vendor from 
whom merchandise is purchased to allow the vendor to ship the item(s) purchased to the 
consumer. If the Multi-Vendor Internet Commerce System (MV-ICS) also acts as the 
merchant of record, some vendors may not even need to have any type of credit card point-of- 
sale facility and may instead arrange with the Multi- Vendor Internet Commerce System (MV- 
ICS) to allow the Multi-Vendor Internet Commerce System (MV-ICS) to charge the consumer 
for the purchased item(s) and to forward payment, either for each item or for batches of items, 
to the vendor (e.g., in the form of a check from the Multi- Vendor Internet Commerce System 
(MV-ICS) service). Again, the vendor may not need to receive the shipping data (and the 
payment data, if the vendor is the merchant of record) via a web-based mechanism. In this 
manner, the additional technology investment by an existing brick-and-mortar vendor to 
become e-commerce enabled may be kept to a bare minimum. 

Further, the fact that many of the resources pertaining to the consumer, the universal 
shopping cart facility, the checkout facility, the gift registry, and the like, are shared across 
multiple independent and geographically dispersed vendors offers many of the benefits 
previously unattainable when these facilities are implemented piece-meal and in an isolated 
manner in each vendor website. 

By way of example, the availability of the cross-vendor universal shopping cart opens 
up many applications previously impractical when a consumer may have dozens or hundreds of 
isolated shopping carts scattered among vendor websites across the Internet. Exemplary 
applications include comparison shopping across vendors for the consumer, bidding on the 
items in the universal shopping basket by vendors (e.g., to propose a better quality or a lower 
price than those associated with an item picked by the consumer). As another example, cross- 
vendor gift registries and discount programs may now be available since they may be applied to 
the cross-vendor shopping cart, the cross-vendor checkout procedure, and the cross-vendor 
registries at the centrally implemented Multi-Vendor Central System (MV-CS). As a further 
example, there may be provided a historical order profile feature wherein items that have been 
purchased earlier are kept in a historical order profile section of the universal shopping cart. 
Since the items therein have links to the respective page of the vendor product offering page of 
the respective vendor website, the consumer may not only review a history of items already 
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ordered but may also track back (by clicking on the item listed in the historical profile section, 
for example) and review the product offering page (and back to the respective vendor) for 
purposes such as warranty registration, customer service, etc., all from the universal shopping 
cart. 

For the consumer, the need to use only a single universal shopping cart and a single 
checkout procedure substantially eliminates the confusion associated with the use of different 
shopping cart interfaces, different checkout interfaces, and different navigation steps when 
these facilities are implemented in a proprietary fashion by the vendor websites. With one 
shopping cart interface, one gift registry interface, and one checkout procedure, the consumer 
has less to learn and become accustomed to, which may open the e-commerce door to many 
consumers who, up to now, may have been intimidated by the confusing variety of shopping 
cart interfaces and procedures, checkout interfaces and procedures, and navigation steps that 
are implemented by each vendor. If there is any edit to the consumer profile, the fact that there 
is only one centralized place to perform consumer profile edits advantageously simplifies such 
task for the consumer. 

Further, the fact that the consumer profile is kept at a centralized, trusted facility (e.g., 
the Multi -Vendor Internet Commerce System (MV-ICS)) improves the security of the 
confidential consumer data. The loss of control over personal, confidential, financial, and/or 
other data is a fear that has kept many consumers out of e-commerce and if necessary, the 
invention makes it possible to send only the shipping data and the identification of the items to 
be shipped to the vendor (i.e., in the case where the Multi- Vendor Internet Commerce System 
(MV-ICS) service also acts as the merchant of record). In this case, there is no risk of having 
the personal confidential payment data being kept at multiple vendors since the vendors no 
longer need the payment data to perform the settlement action. 

In one embodiment, the Multi -Vendor Internet Commerce System (MV-ICS) may also 
contract with the shipping partners (e.g., UPS, the US Post Office, FedEx, etc.) to implement a 
database and coding system wherein the user's name (and even address) may be made 
anonymous and known only to the Multi-Vendor Internet Commerce System (MV-ICS) and the 
shipping partners. The anonymous identity and address (e.g., any unique string or strings of 
alphanumerics or image or images) may be furnished to the vendor and once the shipped 
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package arrives at the shipping partner, the shipping partner may decipher the anonymous 
identity (and address, such is also anonymous) to obtain the correct identity and shipping 
address to facilitate shipping to the purchaser. 

It is realized by the inventor(s) herein that the present invention is particularly well 
suited to the printed catalog industry for use as a vehicle to enable its vendors to sell their 
merchandise through the Internet with minimal additional investment on the part of the 
vendors. The tens of thousands of printed catalog vendors currently existing in the United 
States, for example, are mostly independent of one another, and many are small operations 
which do not have the resources necessary to implement the necessary proprietary 
infrastructures to become vendors on the Internet using the prior art paradigm. However, each 
of these vendors have adapted over time to provide printed catalogs, to have a settlement 
procedure to receive checks via mail or credit card information from the consumers over the 
phone or fax, which allow the vendor to charge the consumer for the items purchased, and to 
have a shipping procedure to ship the purchased item to the consumer using the shipping 
information provided by the consumers. 

The same infrastructures can be readily and inexpensively adapted, using the inventive 
Multi-Vendor Internet Commerce System (MV-ICS), to allow such vendors to become e- 
commerce enabled. By way of example, the available printed catalogs can be readily turned 
into linkable pages using scanners and readily available web-page building tools. If necessary, 
a web-design service or a hosting firm may be engaged to turn the catalogs from their paper 
format into an electronic, linkable display, which is viewable by consumers through the 
Internet. The vendor-site I/O module, which may be a data-driven HTML code, may be pasted 
or attached to each item or displayable page, and which includes descriptive text/graphics/price 
of the items to be sold. Again, the invention has reduced the act of linking the selectable items 
to simply linking the item to be selected to the codes that send the item description to the 
Multi- Vendor Central System (MV-CS) through the Internet. The vendors may then furnish, 
using any communication medium, the vendor profile (e.g., contact address, shipping and 
handling schedules, tax tables, etc.) to the Multi-Vendor Internet Commerce System (MV- 
ICS). From then on, the MV-ICS handles the interaction with the consumer via its centrally 
implemented cross-vendor authentication/registration facility, its centrally implemented cross- 
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vendor shopping cart facility, its centrally implemented cross- vendor gift registry, and its 
centrally implemented cross- vendor checkout procedure. Each vendor may then receive its 
vendor-specific shipping information (and the payment data, if the vendor acts as the merchant 
of record which most paper catalog vendors are set up to do) to allow the vendor to charge the 
consumer for the items bought and to ship the items bought to the consumer. 

In fact, it is realized that the invention is also readily adaptable to aggregator sites (such 
as sites that aggregate catalog databases and implement searching and/or price/feature 
comparison) to create a whole new business model wherein the aggregator site may act as the 
Multi- Vendor Internet Commerce System (MV-ICS) provider and provide a cross-vendor 
clearing house for items displayed, selected, and purchased through the aggregator site using 
the centrally implemented Multi-Vendor Central System (MV-CS) which the aggregator site 
implements. Examples of such sites includes portals (e.g., America Online, Yahoo, Excite, 
Alta Vista, etc.), comparison shopping sites, banks, sites associated with credit card companies 
(e.g., Visa, Mastercard, American Express, Discover, etc.). In one implementation of this 
model, many of the databases of electronically viewable merchandise displays may be 
maintained by the underlying vendors. Once the consumer views the search result provided by 
the aggregator site and clicks through to the underlying display page(s), the vendor-site I/O 
modules implemented thereon will allow the Multi-Vendor Central System (MV-CS) to 
perform its cross-vendor shopping cart, checkout, authentication/registration, and registries 
functions in the manner discussed earlier. 

The above-discussed features, as well as additional features, user- interface, and 
navigation techniques relevant to some exemplary implementations of the inventive Multi- 
Vendor Internet Commerce System (MV-ICS) are shown in the series of screenshots 
submitted herewith as screenshots A1-A46 and B1-B14. 

While this invention has been described in terms of several preferred embodiments, 
there are alterations, permutations, and equivalents which fall within the scope of this 
invention. Therefore, the above description should be understood to be instructive as to 
some exemplary implementations and not limiting of the true scope of the present invention. 
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